A Case in Point: Verification and Testing of a EULYNX Interface

We present a case study on the application of formal methods in the railway domain. The case study is part of the FormaSig project, which aims to support the development of EULYNX — a European standard defining generic interfaces for railway equipment — using formal methods. We translate the semi-formal SysML models created within EULYNX to formal mCRL2 models. By adopting a model-centric approach in which a formal model is used both for analyzing the quality of the EULYNX specification and for automated compliance testing, a high degree of traceability is achieved. The target of our case study is the EULYNX Point subsystem interface. We present a detailed catalog of the safety requirements, and provide counterexamples that show that some of them do not hold without specific fairness assumptions. We also use the mCRL2 model to generate both random and guided tests, which we apply to a third-party software simulator. We share metrics on the coverage and execution time of the tests, which show that guided testing outperforms random testing. The test results indicate several discrepancies between the model and the simulator. One of these discrepancies is caused by a fault in the simulator, the others are caused by false positives, i.e. an over-approximation of fail verdicts by our test setup

mCRL2 models, requirements and test logs for the EULYNX Point interface case study

mCRL2 models and mu-calculus formulas for the EULYNX Point Interface. Models and requirements are made in the context of the FormaSig project. Data is made available for replication purposes. REQ_P_001, REQ_P_001_1 and REQ_P_002 are requirements for the point specific mCRL2 model point_spec.mcrl2 Remaining .mcf files are requirements for the generic PDI interface pdi_spec.mcrl2 Artifacts relating to testing are: An mCRL2 model, mbt.mcrl2A rename file to rename internal actions to tau, rename_file.rePartial state space associated to mbt.mcrl2, partial_state_space.autThe weak-trace bisim reduced version of the state space, partial_state_space_reduced.autTesting logs, test-logs.zipThe source code of the simulator and the testing tools, Simulator code.zi

Source code of the jEULYNX prototype framework

A prototype version of the jEULYNX prototype framework, which uses an internal domain-specific language to capture SysML diagrams as digital models. It also contains several exports for the models, in particular to the process algebra mCRL2.</div

Source code of the jEULYNX prototype framework

A prototype version of the jEULYNX prototype framework, which uses an internal domain-specific language to capture SysML diagrams as digital models. It also contains several exports for the models, in particular to the process algebra mCRL2.</div

What is the point: Formal analysis and test generation for a railway standard

EULYNX is an EU-level collaboration between railway infrastructure managers to standardize signaling interfaces. The main goal of EULYNX is to provide, on an EU scale, a modular and flexible railroad architecture where components can easily be exchanged. This also opens the market for specialized manufacturers that do not supply the full range of control assets, but only single components. Related to EULYNX is FormaSig, an effort to establish the safety of the EULYNX standard with mathematical rigor. In particular, one of the main objectives of FormaSig is to translate the entire EULYNX standard from the semi-formal language SysML to the formal language mCRL2. The resulting mCRL2 models will subsequently be checked for important safety requirements and used for automated testing of actual EULYNX systems. This paper presents a first case study in this direction, focusing on the EULYNX Point interface, which we have converted to an mCRL2 model. We have also derived nine safety requirements, which have all been automatically compared with the mCRL2 model. Finally, we have used the mCRL2 model to test an industrial simulator of the EULYNX Point interface fully automatically